Digital communication protocols are well known in the art of computer engineering as a means for enabling the standardized exchange of data between different devices or components.
It is known that different commands may be sent from a source device to a destination device in a given logical protocol. FIG. 1A shows the flow of commands sent by a source device (for example, a personal computer or a mobile phone) to a destination device (for example, a USB flash drive or an SD card) using logical protocol A. Command #1 (00110100 01010100) is sent from the source device to the destination device. The command is interpreted by the destination device and is executed. When the command execution is completed, a second command is sent by the source device (10110100 11001100) and it is followed by command #3 (01011000 01011010), command #4 (10111000 10001010), and so on, through to the last command #71 (01010100 01001010).
Different protocols may require different physical connections (e.g. having a different number of wires or different timing of signals). Therefore it is common to distinguish between physical interfaces and logical protocols. Different logical protocols may also share the same physical interface or physical protocol, but differ in the meaning of the logical data that is communicated.
For example, the MultiMediaCard™ (MMC) physical protocol accommodates the Serial Advanced Technology Attachment (SATA), Consumer Electronics ATA (CE-ATA), and Secure Digital Input Output (SDIO) logical protocols.
When one or more logical protocols are used on a particular physical inter-device interface, both parties (i.e. each of the at least two devices sending and/or receiving information via the inter-device physical interface) need to “know” or determine which logical protocol is being used for communication.
In some cases, both sides “understand” only one logical protocol (i.e. are configured to issue and/or interpret commands according to only one logical protocol). In this “simple” case, the two or more devices may communicate with each other using the “single allowable logical protocol” whenever connected to each other via the correct physical interface. One typical example related is the case of the USB protocol, where both the physical interface and the logical protocol are uniquely defined. Thus, in the example, the physical USB interface “supports” a single logical protocol, namely the USB protocol.
However, in other cases in computer engineering, it is necessary, during operation, for a device to handle commands of different logical protocols received via a particular physical interface. Towards this end, the “command receiving” device must determine in which protocol to interpret any received commands (i.e. the command receiving device must select the “most correct” protocol from a plurality of possible logical protocols). Sometimes, after receiving a sequence of commands that are in a “first” logical protocol, the “command receiving” device (e.g. a peripheral device which receives commands from a host device) must “effect a protocol mode switch” and interpret the next command in a “second” and different logical protocol.
One example of a device capable of handling commands in different logical protocols received via the same physical inter-device interface is a USB Flash Disk (UFD), such as the XA-HD500® mass storage device available from JVC America Corporation or the Sansa® media player sold by Sandisk Corporation, Milpitas, Calif. Each of these devices supports both Media Transfer Protocol (MTP) and Mass Storage Class protocols when connected to a personal computer via a USB “physical inter-device interface.”
In many examples, the switching between the protocols is frequent, and the commands of both protocols are practically interleaved. This does not pose a problem as long as (i) the two logical protocols do not share any common or “ambiguous” commands and each command on the channel is valid in no more than one of the two or more logical protocols (it can also be not valid in any of the protocols), or, alternatively, (ii) if each data packet is associated with an identifier of the sender or the receiver—information that is sufficient to identify the protocol.
Unfortunately, such “sterile” separation between logical protocols is not always possible, and two protocols employed on the same physical interface may find themselves sharing the same valid commands.
One example of a use case where an ambiguous command is received from a host device by a peripheral device is shown in FIG. 1B.
FIG. 1B shows the flow of commands sent by a source device to a destination device using two different logical protocols, A and B, over the same physical interface. As shown, command #2 (reference number 11) of protocol A is identical to command #33 (reference number 21) of protocol B. Thus, commands 11 and 21 are examples of “ambiguous” commands which are syntactically valid both in protocol A and in protocol B.
In FIG. 1B, the first command in protocol A is sent with the value 00110100 01010100. Then the second command (reference number 11) in protocol A is sent by the source device with the value 00110100 10010100. When the second command in protocol A has been executed by the destination device, the source device side switches to protocol B and sends the first command in protocol B, 01011000 01011010. The source device then switches back to protocol A and sends the fourth command in protocol A, 10111000 10001010. This switching may continue, as indicated by the ellipsis in the figure. After the source device sends command #68 in protocol A, the source device again switches from protocol A to protocol B and sends command #33 (reference number 21) in protocol B. Command #33 (with value of 00110100 10010100) is syntactically valid in both protocol B and protocol A; it has the same value as command 2 (reference number 11) in protocol A but with a different meaning.
Command Identifiers
FIG. 1C describes a use case where a so-called “logical protocol identifier” is associated with each command. As in FIG. 1B, FIG. 1C shows the flow of commands sent by a source device to a destination device using logical protocol A and logical protocol B over the same physical interface. However, in FIG. 1C the syntax of both logical protocols A and B includes an identifier. The identifier is a part of the command and indicates (directly or indirectly) the identity of the protocol for the current command. For example, an identifier can be:                The Ethernet port number, from which the logical protocol (as well as the client application and the server application) can be derived.        The Process ID. Based on a source device process ID, the destination device identifies the relevant protocol.        
In one example, two processes reside on the host device, including a first process (i.e. process X) that sends commands in protocol A, and a second process (i.e. process Y) that sends commands in protocol B. According to this example, a so-called “bus-driver” residing on the host side must ensure that every command from one process (e.g. process X which sends commands in protocol A) is sent completely before a command from the other process (i.e. process Y which sends commands in protocol B) is allowed into the bus, in order to link all command words of the command to the identifier of the command.
Announcement Command
FIG. 1D describes a use case where a so-called “announcement command” is included in the ordered sequence of commands.
As in FIG. 1B, FIG. 1D shows the flow of commands sent by a source device to a destination device using logical protocol A and logical protocol B over the same physical interface. However, in FIG. 1D the syntax of both logical protocols supports an announcement command, which tells the destination device which protocol applies to the subsequent commands. An announcement command can be, for example, one of the following:
1) A source device sends a command in protocol A, to be interpreted as: “Switch now to protocol B and stay in protocol B until further notice”. The “further notice” arrives in protocol B and says: “Switch now to protocol A and stay in protocol A until further notice”.
2) A source device sends a command in protocol A, to be interpreted as: “Switch now to protocol B for 17 commands, and then return automatically back to protocol A”. This mode eliminates both the need for a “return” command and the need to modify the syntax of protocol B.
According to the second type of announcement (i.e. which includes a specific number of commands) the “receiving device” will, upon receiving this announcement commit or set itself to interpreting the next 17 commands (i.e. or whatever other number is specified) in protocol B. The number of commands flagged or assigned to be subsequently executed in protocol B will be 17, in accordance with the “17” of the announcement command.
It is noted that the “announcement command” (51 or 61 or 71) is a “dedicated command” whose only purpose is to indicate a protocol transition.
FIG. 1D illustrates the first type of such an announcement. The first command 51 is an announcement command in protocol A, which informs the destination device that the subsequent commands are in protocol A. The source sends commands in protocol A. The last command in protocol A is command #36 (not shown). The source device then sends one more command in protocol A, command #37 (reference number 61), which is an announcement command in protocol A saying “switch to protocol B”. The destination and the source device switch to protocol B accordingly. The next commands sent by the source to the destination device are in protocol B. Specifically, in FIG. 1D, the next command in the sequence is the first command that is sent in protocol B (value: 00111000 10011010), and protocol B prevails until the source device sends command #12 (still in protocol B, reference 71), which is an announcement command that says: “switch to protocol A”. Then both the destination device and the source device switch to protocol A. The next commands sent by the source device to the destination device are in protocol A.
As with the previous case (i.e. command identifiers), a so-called “bus driver” residing on the host ensures that once one protocol is announced (e.g. by a “first process” on the host which sends commands exclusively in protocol A), only command words of that protocol are sent until the other protocol (e.g. used by a “second process” in a different process space on the host) is announced.